feat(feishu): persist imported document images - #3033

Please add Feishu-specific verification details:

1. A test screenshot of the parsed/imported result, showing that the image from the Feishu document is rendered correctly after import.
2. A concrete example from a Feishu document after inserting an image, including the generated source Markdown around the image reference, e.g. the exact feishu://image/{file_token} reference, and the rewritten image path/URI after import if available.

This will make it easier to verify that the Feishu image-token parsing and rewrite flow covers the real exported document format.

@qin-ctx Hi, I've uploaded the screenshot to the Screenshots (if applicable) section above.

Feishu-image ingestion deliberately reuses the existing local-file image pipeline. The only Feishu-specific work happens inside the accessor: it downloads each feishu://image/{file_token} reference and lays the bytes out on disk exactly like a plain local Markdown document (a document.md plus a sibling images/ folder with relative references). From that point on, _ingest_local_images and rewrite_image_uris run identically for both sources — no Feishu-specific branch downstream.

Path comparison

Concrete before / after for a Feishu document

1. Converter output (Markdown as produced from the Feishu doc):

![screenshot](feishu://image/boxcnXXXXXXXXXXXXXXXXXX)

2. After the accessor downloads and rewrites — temp_dir layout handed to the parser:

temp_dir/
  document.md          # ![screenshot](images/boxcnXXXXXXXXXXXXXXXXXX.png)
  images/
    boxcnXXXXXXXXXXXXXXXXXX.png

3. After _ingest_local_images + rewrite_image_uris (final, committed form):

![screenshot](viking://resources/.../boxcnXXXXXXXXXXXXXXXXXX.png)

This is byte-for-byte the same shape a plain local doc.md + ./images/pic.png ends up in — the only difference is where the bytes came from (Feishu Drive API vs. already on disk).

Notes

• Download failure is non-fatal. If _download_image returns None (e.g. missing scope docs:document.media:download), the token is skipped and its original feishu://image/... reference is left in place; the rest of the import still succeeds (feishu_accessor.py:329-330).

@qin-ctx Thanks for the thorough review.！All three blocking issues are addressed in the latest commit:

1. Sync download on the async path — the media download now runs via asyncio.to_thread, following the existing _fetch_document() pattern, so it no longer blocks the event loop.
2. Hardcoded .png — the extension is now sniffed from the image bytes (byte magic), falling back to the response Content-Type via the existing mime_types.get_preferred_extension helper, so JPEG/WebP/GIF are no longer mislabeled as PNG downstream.

4. Tenant-only media auth — the download request now advertises AccessTokenType.USER when a user access token is supplied (confirmed against lark_oapi.core.token.auth.verify), so user-token imports keep their images instead of silently dropping them.

Added unit tests covering extension detection (Content-Type + byte magic), the event-loop offload, and both the tenant- and user-token request paths.

One note on the byte-magic sniffing: I'm aware this logic is conceptually duplicated across the codebase — http_accessor._detect_from_magic_bytes and the three VLM backends' _detect_image_format all sniff image magic bytes. I deliberately kept a small local copy here rather than reuse them, because none is directly reusable: http_accessor returns (URLType, ext) tuples tied to its URL-classification flow, and the VLM helpers return format-name strings for API payloads — neither maps cleanly to "bytes → file extension." Factoring these into a shared helper (e.g. mime_types.sniff_image_extension) and migrating all call sites feels out of scope for this PR and touches unrelated modules (VLM backends). I'd suggest doing that consolidation in a dedicated follow-up PR. Happy to file it if you agree.